# Version numbering
A quick guide to the version scheme and what it means for you.
# The scheme: YY.MAJOR.MINOR.BUILD
Example: 26.4.1.0
| Segment | Meaning |
|---|---|
| YY | Year — for readability only; it never decides anything. |
| MAJOR | The generation. Never resets. |
| MINOR | Corrective release on that MAJOR. |
| BUILD | Rebuild counter (normally 0). |
# When does MAJOR change?
A new MAJOR = new/changed behaviour: new features, behavioural changes, and (when needed) breaking changes.
- A breaking MAJOR is called out in the changelog, annotated with BREAKING CHANGE — don't expect an increase in breaking changes compared to before.
- New feature for a customer? They upgrade to the latest MAJOR. Features are never added to older versions.
# When does MINOR change?
A MINOR upgrade is safe by design. It contains only fixes and documentation — no new features, no behavioural changes. You can apply a MINOR upgrade without expecting surprises.
- A hotfix is just a MINOR increase (e.g.
26.4.0.0→26.4.1.0).
# Hotfixes — the practical part
- We only hotfix older MAJOR versions (older lines never get features, only fixes).
- There is one open line per MAJOR. A customer taking a hotfix moves to the tip of that MAJOR line — so they get all hotfixes shipped on that MAJOR since their install, but none of master's new development.
- By default a hotfix lands on the requested MAJOR line + master only. If it's requested or critical, we apply it to multiple MAJOR lines.
When requesting a hotfix
Please note the SP version the bug occurs on — we need it to target the right release line.
# Transition — older (pre-scheme) versions
Versions from before the new scheme use the old date format (e.g. 2026.06.02.1155). During the transition these are parked in the legacy bucket 26.0.x.x:
- MAJOR = 0 — marks a legacy, pre-scheme build.
- MINOR — identifies the customer/baseline (a different number per customer).
- BUILD — that customer's hotfix counter on their legacy line.
Example: a hotfix for the customer on 2026.06.02.1155 becomes 26.0.1.0. The next legacy customer gets 26.0.2.x, and so on.
Prefer upgrading to the latest version
The legacy bucket is a temporary holding pen for customers who cannot move yet — hotfixing a pre-scheme build is the exception, not the default.
# Quick reference
- Need a fix on your current version? → hotfix → next MINOR on your MAJOR line (you also pick up earlier hotfixes on that line).
- Need a new feature? → upgrade to the latest MAJOR.
- Upgrading MINOR? → safe, fixes/docs only.
- Upgrading MAJOR? → read the changelog for behavioural/breaking notes.